ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/tsql/doc/tsql.mail/[e-mail] _Tue Mar 30 17:04:31 1993.msg

Internet Message Format | 1996-01-31 | 1KB

Received: from ctt.ctt.bellcore.com by optima.cs.arizona.edu (5.65c/15) via SMTP
    id AA21683; Tue, 30 Mar 1993 15:04:34 MST
Received: from garfield.ctt.bellcore.com by ctt.ctt.bellcore.com (4.1/1.34)
    id AA17803; Tue, 30 Mar 93 17:04:31 EST
Date: Tue, 30 Mar 93 17:04:31 EST
From: Gene Wuu <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: comments

This version looks good. A few comments to add.

The restriction of "Nested queries are not include" may not be necessary.
I take "Nested queries" to mean query blocks that are nested in the WHERE clause
(or even the FROM clause, as allowed in SQL2).
Nested queries are one of several different ways
to solve the same English query. But they have nothing to do
with the English query itself.

However I see the need to restrict "complex data retrieval", e.g.,
retrieving hierarchical data. One popular proposal is to nest query blocks
in the SELECT clause.

I would like to see aggregation to be addressed soon,
if not in the first version.

In the inventory of future extensions, we may want to
keep a note on "inheritence (subtyping)" in the sense of both schema and query.
For example Mgr is a subtype of employee. (The current SQL3 draft has included
most OO features.)
Nevertheeless, we may not want to deal with subtyping in early versioins
of the benchmark work.


-Gene Wuu